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Abstract 

Examples  form  an  integral  and  very  important  part  of 
many  descriptions,  especially  in  contexts  sucb  as  tutor¬ 
ing  and  documentation  generation.  The  ability  to  tailor  a 
description  for  a  particular  situation  is  particularty  impor¬ 
tant  wbm  different  situations  can  result  in  widely  vary¬ 
ing  descriptions.  Tbis  paper  considers  tbe  generation  of 
descriptions  with  examples  for  two  differoit  situations: 
introduaory  texts  and  advanced,  reference  manual  style 
texts.  Previous  studies  have  focused  on  any  tbe  exam¬ 
ples  or  tbe  language  con^nent  of  tbe  explanation  in 
isolation.  However,  there  is  a  strong  interaction  between 
tbe  examples  and  tbe  accompanying  description  and  it  is 
therefore  important  to  study  how  both  these  components 
are  affected  by  changes  in  tbe  situation. 

In  this  paper,  we  characterize  exanq)Ies  in  the  context 
of  their  description  along  three  orthogonal  axes:  the  in¬ 
formation  content,  tbe  knowledge  type  of  the  example 
and  the  text-type  in  which  tbe  explanation  is  being  gen¬ 
erated.  While  variations  along  either  of  tbe  three  axes 
can  result  in  different  descriptions,  tbis  paper  addresses 
variatfon  along  the  text-type  axis.  We  illustrate  our  dis¬ 
cussion  with  a  description  of  a  list  from  our  domain  of 
LISP  documentation,  and  present  a  trace  of  the  system  as 
it  generates  these  desoiptions. 


Introduction 

Exanqiles  are  an  integral  part  of  many  descriptions,  especially 
in  contexts  such  as  tutoring  and  documentation  goieration. 
Indeed,  the  importance  of  using  illustrative  exan^iles  in  com¬ 
municating  effeetively  has  long  been  recognized,  e.g.,  (Green- 
wald  1984;Doheny-Farina  19^;  Norman  1988).  People  like 
examples  becwse  examples  tend  to  put  abstract,  theoretical 
information  into  concrete  terms  they  can  understand.  In  fact, 
one  study  found  that  76%  of  users  looking  at  system  documen¬ 
tation  initially  ignored  the  description  and  went  straight  to  tbe 
exanqiles  (L^evre  and  Dixon  1986).  A  system  that  generates 
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descriptions  must  thus  be  able  to  include  examples.  Fyirtba-- 
more,  tbe  ability  to  tailor  a  description  for  a  particular  situation 
is  particularly  important  as  different  situations  can  result  in 
widdy  varying  descriptions,  where  both  tbe  textual  descrip¬ 
tions  and  the  accompanying  examples  vary.  Some  researchers 
have  already  looked  at  how  a  textual  description  can  be  af¬ 
fected  by  different  situations  (or  different  users),  e.g.  (Paris 
1988;  Batonan  and  Paris  1989).  Others  have  studied  bow 
to  construct  or  retrieve  appropriate  examples,  e.g.  (Rissland 
and  Soloway  1980;  Ashley  and  Aleven  1992;  Rissland  1983; 
Suthers  and  Rissland  1988).  However,  the  issue  of  tailoring 
descriptions  that  include  examples  for  the  situation  at  hand 
has  not  been  addressed.  Yet,  it  is  clear  that  one  cannot  plan 
a  description  tailored  to  a  user,  and  then  indqpendently  and 
as  an  afterthought,  add  some  examples  to  tbe  description: 
Sweller  and  his  colleagues  found  that  if  tbe  examples  and  tbe 
descriptive  component  were  not  well  integrated,  tbe  combi¬ 
nation  could  result  in  reduced  user  comprdbension  (Chandler 
and  Sweller  1991;  Ward  and  Sweller  1990).  Examples  and 
text  must  be  presented  to  tbe  user  as  a  coherent  whole,  and 
together,  appropriately  tailored  to  tbe  situation. 

Because  examples  are  crucial  in  documentation  (Cbamey, 
Reder,  and  Wells  1988;  Fddman  and  Klausmeier  1974;  Klaus- 
meier  and  Feldman  1975;  Reder,  Cbamey,  and  Morgan  1986), 
and  documentation  is  a  critical  factor  in  user  acceptance  of 
a  system,  we  chose  automatic  documentation  as  our  domain 
to  investigate  tbe  issue  of  generating  descriptions  that  include 
examples.  This  domain  has  additional  advantages:  there  is 
a  large  body  of  work  on  documentation  writing,  a  lot  of  ac¬ 
tual  material  that  we  can  study,  including  numerous  examples 
of  the  text  types  we  are  concerned  with  (introductmy  and 
advanced),  b  previous  work,  we  have  described  tbe  issues 
that  must  be  addressed  for  a  system  to  be  able  to  graerate 
descriptions  with  well  integrated  examples  (Mittal  and  Paris 
1992).  In  this  paper,  we  show  bow  two  qiecific  situations, 
introductory  texts  and  advanced  texts,  result  in  two  different 
sud)  descriptions. 

Tbis  paper  is  structured  as  follows:  Section  2  briefly  reviews 
the  issues  that  arise  when  generating  text  with  examples.  Sec¬ 
tion  3  presets  a  categorization  of  example  types  that  allows 
us  to  provide  a  diaracterization  of  the  differences  between  tbe 
texts  in  inuroductory  vs  references  manuals  and  Section  4  dis¬ 
cusses  these  differences.  Sections  describes  our  text  planning 


A  list  always  begins  with  a  left  parenthesis.  Then  come 
zero  or  more  pieces  of  data  (called  the  elements  of  a  list) 
and  a  right  parenthesis.  Some  examples  of  lists  are; 
(USPVAIUC) 

(RED  YBXXOU  GRBBI  BLUB) 

(2  3  6  11  19) 

(3  FRSICE  FRIES) 

A  list  may  contain  other  lists  as  elements.  Given  the  three 
yste: 

(BLUE  SKY)  (GREBI  GRASS)  (BROVI  BiRTB) 
we  can  make  a  list  by  combining  them  all  with  a  paren¬ 
theses. 

((BLUE  SKY)  (GREEl  GRASS)  (BROVI  BARTS)) 

Figure  1:  A  description  of  list  in  an  introductory  text 
from  (Touretzky  1984),  p.35 


framework,  and  Section  6  presents  a  trace  of  the  algorithm. 
Section  7  concludes  with  a  look  at  the  limitations. 

Integrating  Examples  in  Descriptive  T^xts 

Many  issues  need  to  be  considered  when  generating  descrip¬ 
tions  that  integrate  descriptive  text  and  examples,  because  both 
these  components  co-constrain  and  affect  each  other.  The  in¬ 
clusion  of  examples  in  an  explanation  can  sometimes  cause 
additional  text  to  be  generated;  at  other  times,  it  can  cause 
certain  portions  of  the  original  explanation  to  be  dided.  A 
generation  system  must  therefore  take  into  account  the  inter¬ 
action  between  the  descriptive  text  and  the  examples,  as  well 
as  effects  from  other  factors,  such  as  the  presentation  order  of 
the  examples,  the  placement  of  the  examples  with  respect  to 
each  other,  as  well  as  the  descriptive  text,  etc. 

While  we  have  discussed  these  issues  elsewhere  (Mittal  and 
Paris  1992;  Mittal  ming),  we  review  some  of  them  here: 

•  What  should  he  in  the  text,  in  the  examples,  in  both? 

•  What  is  a  suitable  example?  How  much  information  should 
a  single  example  attempt  to  convey?  Should  there  be  more 
than  one  example? 

•  If  multiple  examples  are  to  be  presented,  what  is  the  order 
of  presentation? 

•  If  an  example  is  to  be  given,  should  the  example  be  pre¬ 
sented  immediately,  or  after  the  whole  description  is  pre¬ 
sented?  This  will  determine  whether  the  example(s)  appear 
within,  b^ore,  or  ofier  the  descriptive  text. 

•  Should  prompts*  be  generated  along  with  the  examples? 

Answers  to  these  questions  will  depend  on  whether  the  text 
is  an  introductory  or  advanced  text.  Consider,  for  example, 
the  descriptions  of  liat  given  in  Fig.  1  takoi  from  (Touretzky 
1984),  an  introductory  manual,  and  Hg.  2  taken  from  (Steele 
Jr.  1984),  a  reference  manual:  they  contain  very  different 
information  in  both  their  descriptive  portions  as  well  as  thdr 
exanqiles;  while  Hg.  1  contains  8  lists  (which  are  used  either  as 
exanqtles  or  as  background  to  the  exanq>les),  Hg.  2  has  only 

'  ‘Prompts*  are  attenlioD  focusing  devices  such  u  snows,  marks, 
or  even  additional  text  associated  with  examples  (Engelmann  and 
Camine  1982). 


A  list  is  recursively  defined  to  be  either  the  empty  list 
or  a  cois  whose  COR  component  is  a  list.  The  CAR 
components  of  the  coises  are  called  the  elements  of  the 
list.  For  each  element  of  the  list,  there  is  a  COIS.  The 
empty  list  has  no  elements  at  all. 

A  list  is  annotated  by  writing  the  elements  of  the  list 
in  order,  separated  by  blank  space  (space,  tab,  or  return 
character)  and  surrounded  by  parentheses.  For  example: 

(a  b  c)  :  A  list  of  3  symbols 

(2.0s0  (a  1)  t\a)  ;  A  list  of  3  tbingsia 
:  floating  point  nnmbar, 

;  another  list,  and  a 
;  character  object 

Figure  2;  A  description  of  list  from  a  reference  manual 
from  (Steele  Jr.  1984),p.26 


2  examples.  Finally,  the  exanq)les  in  Fig.  1  do  not  contain 
prompts,  while  those  in  Hg.  2  do. 

Categorizing  Example  Types  in  Context 

In  order  to  provide  appropriately  tailored  examples,  we  must 
first  characterize  the  type  of  examples  that  can  appear  in  de¬ 
scriptions.  This  will  then  help  the  systm  in  choosing  tqipro- 
priate  examples  to  present  as  part  of  a  description. 

While  some  example  categorizations  (Michener  1978; 
Polya  1 973)  have  already  been  proposed,  we  found  these  inad¬ 
equate  as  they  do  not  take  the  context  of  the  whole  explanation 
into  account.  This  is  because  previous  attempts  at  categorizing 
example  types  were  done  in  an  analytical  r^er  (ban  a  gener¬ 
ational  context,  and,  as  a  result,  these  categorizations  suffered 
from  two  drawbacks  from  the  standpoint  of  a  computational 
generation  system:  (i)  they  do  not  explicitly  take  into  account 
the  context  ir  which  the  example  occurred,  and  (»)  they  did 
not  differentiate  among  different  dimensions  of  variation. 

An  example  of  how  important  the  context  is  in  determining 
the  category  of  the  example  can  be  seen  if  we  look  at  the  two 
descriptions  of  a  list,  shown  in  Fig.  3,  taken  from  our  lisp 
domain.  The  empty  list  IIL  is  an  anomalous  example  for  the 
first  definition,  while  it  is  a  positive  example  for  the  second 
one.  Thus  it  is  clear  that  categorization  d^nds  upon  not  only 
the  example,  but  the  surrounding  context  (which  includes  the 
descriptive  text  accompanying  the  example)  as  well. 

Based  on  our  analysis  of  a  number  of  instructional  texts, 
numerous  reference  manuals  and  large  amounts  of  system 
documentation,  we  formulated  a  three  dimensional  system 
to  categorize  examples  by  explicitly  taking  the  context  into 
account.  The  three  dimensions  are;^ 

1.  the  polarity  of  the  example  with  respect  to  the  description: 
It  can  be:  (t)  positive,  i.e.,  the  example  is  an  instance  of 
the  description,  (ti)  negative,  i.e.,  the  example  is  not  an 
instance  of  the  description,  or  (ttT)  anomalous,  i.e..  the 
example  either  looks  positive  and  is  actually  negative,  or 
vice-versa. 


^Fiutfaer  details  on  this  classificatioD  of  examples  into  a  three 
dimensional  space  may  be  found  in  (Mittal  and  Paris  1993). 


A  left  parenthesis  followed  by  zero  or  more  S-expressions 
followed  by  a  right  parenthesis  is  a  list 

From  (Shapiro  1986) 


A  list  is  recursively  defined  to  be  either  the  empty  list 
or  a  COIS  whose  COR  component  is  a  list.  The  CAR 
components  of  the  coises  are  called  the  elements  of  the 
list.  For  each  element  of  the  list,  there  is  a  COIS.  The 
empty  list  has  no  elements  at  all.  The  empty  list  IIL 
therefore  can  be  written  ( ),  because  tt  is  a  list  with  no 
elements. 

From  (Steek  Jr.  1984) 

Figure  3:  TWo  definitions  that  cause  IIL  to  be  classified  dif- 
faently  as  an  illustrative  example. 


2.  the  knowledge  type  being  communicated:  for  example,  a 
concept,  a  relation  or  a  process  is  being  described. 

3.  the  genre  or  text-type  to  be  generated:  For  now.  we  only 
take  into  consideration  two  text-types:^  (t)  descriptions  in 
introductory  texts,  and  (tt)  descriptions  in  reference  manu¬ 
als.  These  are,  in  our  case,  closely  related  to  the  user  types: 
introductory  texts  are  intended  for  beginners  and  naive  users 
while  advanced  texts  are  intended  for  expert  users.^ 

Note  that  each  of  these  axes  can  be  further  sub-divided  (for 
instance,  concepts  can  be  further  specified  as  being  single- 
featured  or  multi-featured  concqtts,  etc.). 


Such  a  categorization  is 
essential  to  narrow  the 
search  space  for  suitable 
examples  during  genera¬ 
tion.  Furthermore,  it  al¬ 
lows  us  to  make  use  of  the 
numerous  results  in  educa¬ 
tional  psychology  and  cog¬ 
nitive  science,  on  how  to 
best  choose  and  present  ex¬ 
amples  for  a  particular  text- 
and  knowledge-type.  For 
example,  results  there  sug¬ 
gest  constraints  that  can  be 
taken  into  consideration  with  respect  to  the  number  of  ex¬ 
amples  to  present,  e.g.,  (Markle  and  Tiemann  1969),  their 
order  of  presentation,  e.g.,  (Gamine  1980;  Engelmann  and 
Gamine  1982),  whether  anomalous  examples  should  be  pre¬ 
sented,  e.g.,  (Ehgelmann  and  Gamine  1982),  etc. 


^We  make  uic  of  the  notion  of  a  lext-type  here  only  in  a  very 
broad  sente  to  de6ne  distinct  categories  that  affect  the  generation  of 
examples  in  our  fiamewoik  for  the  automatic  documentation  task. 
However,  these  text-types  can  be  refined  further.  Indeed,  several 
detailed  text  typologies  have  been  proposed  by  linguists  e.g.,  (Biber 
1989;  de  Beaugrande  1980). 

^We  have  in  fact  referred  to  this  axis  as  'user  type’  in  other  work. 


Figure  4:  Three  dimensions 
for  example  categorization. 


Introductory  Advanced  Texts 

We  now  consider  bow  descriptions  that  contain  examples  dif¬ 
fer,  when  we  move  along  the  text-type  axis  of  our  categoriza¬ 
tion,  from  introductory  to  advanced  text.  We  address  each  of 
the  questions  presented  in  Section  2: 

The  descriptive  componcDt:  In  the  case  of  the  introductory 
text-type,  the  descriptive  component  contains  surface  or  syn¬ 
tactic  information;  in  the  case  of  the  reference  text-type,  the 
description  must  include  complete  information,  including  the 
internal  stmcture  of  the  concept 

The  actual  examples:  Examples  in  both  text-types  illustrate 
critical  features^  of  the  surface  or  syntactic  form  of  tbeconcqit 
or  its  realization.  In  introductory  texts,  boweva,  examples 
are  simple  and  tend  to  illustrate  only  one  feature  at  a  time. 
(Sometimes  it  is  not  possible  to  isolate  one  feature,  and  an 
example  might  illustrate  two  features;  in  this  case,  the  system 
will  need  to  generate  additional  text  to  mention  this  fact.)  On 
the  other  band,  examples  in  reference  texts  are  multi-featured. 
The  Dumber  of  examples:  Since  introductory  texts  contain 
usually  single-featured  examples,  the  number  of  examples  de¬ 
pend  upon  the  number  of  critical  features  that  the  concqit 
possesses.  In  contrast,  reference  texts  contain  examples  that 
contain  three  or  four  features  per  example  (Glark  1971),  and, 
therefore,  proportionately  fewer  examples  need  to  be  pre¬ 
sented. 

The  polarity  of  the  examples:  Introductory  texts  make  use 
of  both  positive  and  negative  examples,  but  not  anomalous 
examples.  Advanced  texts  on  the  other  band,  contain  positive 
and  anomalous  examples. 

The  position  of  the  examples:  In  introductory  texts,  the  ex¬ 
amples  are  presented  immediately  after  the  point  they  illustrate 
is  mention^.  This  results  in  descriptions  in  which  the  exam¬ 
ples  are  interspersed  in  the  text.  On  the  other  band,  examples 
in  reference  texts  must  be  presented  only  after  the  description 
of  the  concq^t  is  complete. 

Prompts:  The  system  needs  to  generate  prompts  for  exam¬ 
ples  that  contain  more  than  one  feature.  The  system  must 
also  generate  prompts  in  the  case  of  recursive  examples  (they 
use  other  instances  which  are  also  instances  of  the  concept), 
and  anomalous  examples  if  background  text  has  not  yet  b^n 
generated  (as  is  done  for  introductory  texts). 

These  guidelines  are  summarized  in  Fig.  S. 

In  the  following  section,  we  will  illustrate  how  a  system 
can  use  these  guidelines  to  generate  descriptions  (text  and 
examples)  for  both  introductory  and  advanced  texts,  in  our 
domain  of  the  programming  language  usp. 

The  Generation  System 

Our  system  is  part  of  the  documentation  facility  we  are 
building  for  the  Explainable  Expert  Systems  (EES)  frame¬ 
work  (Swartout,  Paris,  and  Moore  1992).  The  framework 
implements  the  integration  of  text  and  examples  within  a  text- 
generation  system.  More  specifically,  we  use  a  text-planning 
system  that  constructs  text  by  explicitly  reasoning  about  the 

^Critical  features  are  features  that  are  necessary  for  an  exampk  to 
be  considered  a  positive  exampk  of  a  concept  Changes  to  a  critical 
feature  cause  a  positive  example  to  become  a  negative  exampk. 


communicative  goal  to  be  achieved,  as  well  as  bow  goals  re¬ 
late  to  each  other  rhetorically  to  form  a  coherent  text  (Moore 
and  Paris  1989;  Moore  1989;  Moore  and  Paris  1992).  Given  a 
top  level  communicative  goal  (such  as  (KIOW-ABOUT  HEARER 
(COICEPT  LIST) ).‘ the  system  finds  plans  capable  of  achiev¬ 
ing  this  goal.  Plans  typically  post  further  sub-goals  to  be 
satisfied.  These  are  expanded,  and  planning  continues  imtil 
primitive  speech  acts  are  achieved.  The  result  of  the  planning 
process  is  a  discourse  tree,  where  the  nodes  represent  goals 
at  various  levels  of  abstraction,  with  the  root  being  the  initial 
goal,  and  the  leaves  rq)resenting  primitive  realization  state¬ 
ments,  such  as  (IIFORN  . . . )  statements.  The  discourse 
tree  also  includes  coherence  relations  (Mann  and  Thompson 
1987),  which  indicate  how  the  various  portions  of  text  result¬ 
ing  from  the  discourse  tree  will  be  related  rtietorically.  This 
tree  is  then  passed  to  a  grammar  interface  which  converts  it 
into  a  set  of  inputs  suitable  for  input  to  a  grammar. 

Plan  operators  can  be  seen  as  small  schemas  which  describe 
bow  to  achieve  a  goal;  they  are  designed  by  studying  natural 
language  texts  and  transcripts.  They  include  conditions  for 
their  s^plicability,  which  can  refer  to  the  system  knowledge 
base,  the  usei  model,  or  the  context  (the  text  plan  tree  imder 
construction  and  the  dialogue  history^  In  this  framework,  the 
generation  of  examples  is  accomplished  by  explicitly  posting 
the  goal  of  providing  an  example  while  constructing  the  text. 

A  Drace  of  the  system 

We  now  describe  a  trace  of  the  system  as  it  plans  the  presen¬ 
tation  of  descriptions  similar  to  the  ones  presented  in  Fig.  1 
and  2. 

First,  assume  we  want  to  produce  a  description  of  a  liat 
for  an  introductory  manual.  The  system  is  given  a  top-levei 
goal:  (KIOV-ABOUT  HEARER  (COICEPT  LIST) ).  The  text 
planno'  searches  for  applicable  plan  operators  in  its  plan- 
library,  and  it  picks  one  based  on  the  ^plicable  constraints 
such  as  the  text-type  (introductory),  the  knowledge  type  (con¬ 
cept).  etc.^  The  text-type  restricts  the  choice  of  the  features  to 
present  to  be  syntactic  ones.  The  main  features  of  list  are 
retrieved,  and  two  subgoals  are  posted:  one  to  list  the  critical 
features  (the  left  parenthesis,  the  data  elements  and  the  right 
parenthesis),  and  another  to  elaborate  upon  them. 

At  this  point,  the  discourse  tree  has  only  two  nodes  apart 
from  the  initial  node  of  (KIOV-ABOUT  H  (COICEPT  LIST)): 
namely  (i)  (BEL  H  (NAII-FEATURES  LIST  (LT-PAREI 
DATA-ELMT  RT-PAREl))),  and  (tT)  (ELABORATIOI  FEA¬ 
TURES),'  Which  will  result  in  a  goal  to  describe  each  of  the 
features  in  turn. 

The  planner  searches  for  appropriate  operators  to  satisfy 
these  goals.  The  plan  operator  to  describe  a  list  of  features 
indicates  that  the  features  should  be  mentioned  in  a  sequence. 
Three  goals  are  tqppropriately  posted  at  this  point.  These 


*See  the  refemice*  given  above  for  details  on  the  notation  used 
to  represent  these  goals. 

^Wben  several  plans  are  available,  the  system  chooses  one  using 
selection  heuristics  designed  by  (Moore  1989). 

'BLABORATIOlis  one  of  the  coherence  relations  defined  in  (Mann 
and  Thompson  1987). 


For  each  issue,  the  effect  of  the  text-type  is: 

•  Examples: 

introductory:  simple,  single  critical-feature 
advanced:  coii^>lex,  multiple  critical-features 
e  Accompanying  Description: 

Introductory:  surface,  syntactic  information 
advanced:  complete  information,  including  internal  structure 
e  Number  of  Examples: 

introductory:  depends  upon  number  of  critical  features 
advanced:  few  (each  example  contains  diree  to  four  features) 
a  Positioning  the  Examples: 

introductory:  immediately  after  points  being  illustrated 
advanced:  after  the  description  is  conqilete 

•  Prompts: 

introductory:  prompt  if  example  has  more  than  one  feature 
advanced:  prompts  if  anomalous  and  recursive  examples 

Figure  5:  Brief  description  of  differences  between  examples 
in  introductory  and  advanced  texts. 


goals  result  in  the  planner  generating  a  plan  for  the  first  two 
sentences  of  Fig.  1.  The  other  sub-goal  (the  ELABORATIOI) 
also  causes  three  goals  to  be  posted  for  describing  each  of  the 
critical  features.  Since  two  of  these  are  for  elaborating  upon 
the  parentheses,  they  are  not  expanded  because  no  further 
information  is  available.  So  only  the  goal  of  describing  the 
data  elements  remains.  A  partial  rqiresentation  of  the  resulting 
text  plan  is  shown  in  Fig.  6.’ 

Data  elements  can  be  of  three  types:  numbers,  symbols, 
or  lists.  The  system  can  either  communicate  this  information 
by  realizing  an  appropriate  sentence,  or  through  examples  - 
since  it  can  generate  examples  for  each  of  these  types,  or  both. 
The  text  type  (introductory  text)  constraints  cause  the  sys¬ 
tem  to  pick  examples.  (If  the  text-type  had  been  ‘reference,’ 
the  system  would  have  delayed  the  presentation  of  examples, 
and  text  would  have  been  generated  at  that  point  instead  of 
the  examples.)  The  system  posts  two  goals  to  illustrate  the 
two  dimensions  along  which  the  data  elements  can  vary:  the 
number  of  elements  and  the  type. 

Information  about  a  particular  feature  can  be  communicated 
by  the  system  through  examples  efficiently  by  using  pairs  (or 
groups)  of  examples  as  follows: 

•  if  the  feature  to  be  communicated  happens  to  be  a  critical 
feature,  the  system  generates  pairs  of  examples,  one  positive 
and  one  negative,  which  are  identical  excqit  for  the  feature 
being  communicated,  and 

•  if  the  feature  to  be  communicated  happens  to  be  a  variable^^ 

*A11  the  text  plans  shown  in  this  p^>er  are  simplified  versions  of 
the  actual  plans  generated:  in  particular,  the  communicative  goals  are 
not  written  in  their  fonnal  notation,  in  tenns  of  the  hearer's  mental 
states,  for  readability’s  sake. 

'**Variable  features  are  features  that  can  vary  in  a  positive  example. 
Changes  to  variable  features  creates  different  positive  examples. 
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Hgure  6:  Skeletal  plan  for  listing  main  features  of  list. 


feature,  tbe  system  generates  pairs  of  examples  that  are  both 

positive  and  are  widely  diffo^nt  in  tbat  feature 

Tbus,  to  communicate  tbe  fact  that  there  can  be  any  number  of 
elements,  tbe  system  posts  two  goals  to  generate  two  differing 
positive  examples,  one  with  a  single  element  and  another  with 
multiple  elements.  Tbe  example  generation  algorithm  ensures 
that  the  examples  selected  for  related  sub-goals  (such  as  tbe 
two  ^ove)  differ  in  only  the  dimension  being  highlighted. 
However,  as  the  examples  contain  two  critical  features  (i.e.. 
type  is  illustrated  as  well),  the  system  generates  prompts  to 
focus  the  attention  on  the  reader  on  the  number  feature  (“a  list 
of  one  element”  vj  “a  list  of  several  elements”). 

The  goal  to  illustrate  the  type  dimension  is  handled  in  similar 
fashion,  with  four  sub-goals  (one  each  for  the  types:  symbols, 
numbers,  symbols  and  numbers,  and  sub-lists)  being  posted. 
Tbe  last  data  type,  sub-lists,  is  marked  by  the  algorithm  as  a  re¬ 
cursive  use  of  the  conc^t,  and  is  handled  specially  because  the 
text-type  is  introductory.  In  the  case  of  an  introductory  text, 
such  examples  must  be  introduced  with  appropriate  explana¬ 
tions  added  to  the  text.  (If  the  text-type  bad  been  ‘reference,’ 
tbe  system  would  have  generated  a  prompt  denoting  the  pres¬ 
ence  of  the  sub-list.)  Tbe  resulting  skeletal  text-plan  generated 
by  the  system  is  shown  in  Fig.  7. 

Consider  the  second  case  now,  when  tbe  text-type  is  spec¬ 
ified  as  being  ‘reference.’  In  this  case,  the  system  starts  v/ith 
the  same  top-level  goal  as  before,  but  the  text-type  constraints 
cause  the  planner  to  select  both  tbe  structural  rq)resentation 
of  a  list,  as  well  as  tbe  syntactic  structure  for  presentation. 
The  system  posts  two  goals,  one  to  describe  the  underlying 
structure,  and  one  to  describe  tbe  syntactic  form  of  a  list. 
The  two  goals  expand  into  the  first  two  paragr^tbs  in  Rg.  2. 
Note  tbat  the  exanqtles  occur  at  tbe  end  of  the  description. 
The  two  examples  generated  are  much  more  complex  than  tbe 
previous  case,  and  they  contain  a  number  of  variable  features 
(the  second  example  shows  tbe  variation  in  element  types,  as 
well  as  tbe  variation  in  number  possible).  Since  tbe  second 
exan^le  generated  contains  a  list  as  a  data  element,  the  sys¬ 
tem  generates  prompts  for  the  exanqtles.  For  lack  of  space, 
the  resulting  text  plan  is  not  presented  here.'* 

In  both  of  the  above  cases,  the  completed  discourse  tree  is 
passed  to  an  interface  which  converts  the  IIFORM  goals  into 

"See  (Mittal  ming)  for  more  details. 


Figure  7:  Skeletal  plan  for  generating  examples  of  lists. 


the  appropriate  input  for  the  sentence  generator.  The  intoface 
chooses  the  appropriate  lexical  and  syntactic  constructs  to 
form  the  individual  sentences  and  connects  them  appropriately, 
using  the  rhetorical  information  from  the  discourse  tree. 

Conclusions 

We  have  presented  an  analysis  of  tbe  differences  in  descrip¬ 
tions  that  integrate  examples  for  introductory  and  advanced 
texts.  To  be  able  to  do  this,  we  first  presented  a  brief  descrip¬ 
tion  of  our  characterization  of  examples,  explicitly  taking  into 
account  tbe  surrounding  context.  Variation  along  any  of  these 
axes  causes  tbe  explanation  geno-ated  to  change  accordingly. 
This  variation  occurs  not  just  in  tbe  descriptive  part  of  the  ex¬ 
planation,  but  also  in  tbe  examples  that  accompany  it.  Since 
tbe  examples  and  the  descriptive  component  are  tightly  inte¬ 
grated  and  affect  each  other  in  many  ways,  a  system  designed 
to  generate  such  descriptions  must  take  into  account  these 
interactions  and  be  able  to  structure  the  presentation  accord¬ 
ingly.  We  have  presented  information  necessary  to  generate 
descriptions  for  two  text-types:  infroductory  and-  advanced. 
Tbe  algorithm  used  by  tbe  system  was  illustrated  by  tracing 
tbe  generation  of  two  descriptions  of  tbe  lisp  list. 

The  issues  we  have  described  are  not  specific  to  a  particular 
framework  or  implementation  for  generation  of  either  text  or 
examples.  In  fa^  tbe  algorithm  described  is  implemented 
in  our  system  as  constraint  specification  across  different  plan 
operators.  We  have  successfully  combined  two  wdl-known 
generators  (one  for  text  and  one  for  examples)  in  our  system 
to  produce  the  explanations  described  in  this  paper. 
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